関連性に基づくユーザー・ブラウザー履歴のソーティング

专利摘要:
種々の実施形態は、ユーザーがブラウザーのアドレス・バーにテキストを入力し始めたときに、ユーザーの意する宛先の確度に関して経験に基づく推測を行うために関連性アルゴリズムを採用したウェブ・ブラウザーを提供する。１つ又は複数の実施形態では、関連性アルゴリズムは、種々のパラメータを用い、これらのパラメータに重みを指定して、ユーザーに提供する提案の集合体に到達する。種々の規則、関連する重み付け、および関連性アルゴリズムを用いることにより、ユーザーのナビゲーション活動をし易くするために、関連提案をユーザーに提供することができる。
公开号:JP2011511970A
申请号:JP2010540766
申请日:2008-12-12
公开日:2011-04-14
发明作者:イュング，カルロス；ヴォーグハン，クリストファー・エム；ウォルレース，オリヴァー；グプタ，アミット；マール，クリストフ
申请人:マイクロソフト コーポレーション；
IPC主号:G06F17-30

专利说明:

[0001] [0001] 多くのウェブ・ブラウザーは、自動補完機能を有し、ユーザーがテキスト・ストリングをブラウザーのアドレス・バーにタイプ入力したときに、ユーザーに提案(suggestions)を提供するのを補助する。例えば、ユーザーが特定のウェブ・サイトを検索しているとき、「www.abc.com」をブラウザーのアドレス・バーにタイプ入力することがあり得る。ブラウザーが自動補完機能を有する場合、ユーザーには、多くの場合、ＵＲＦプレフィックス・ストリングのユーザーがタイプ入力したＵＲＬとの照合を行うことによって発見される多数の提案が、ユーザーのブラウズ履歴に含まれるものと共に提供される。例えば、図１は全体的に１００で示すブラウザー・ユーザー・インターフェースの一部を示す。ブラウザー・インターフェース１００は、アドレス・バー１０２をトップ・ダウン・メニュー１０４と共に含み、トップ・ダウン・メニュー１０４は、ユーザーがアドレス・バー１０２に入力したテキストと一致する自動補完提案を提供する。] 図１
発明が解決しようとする課題

[0002] [0002] 生憎、これは、提案全体を検索するために、マウスのクリック、キーの押下等多くのユーザー行為を必要とする可能性があり、ときとしてユーザーは関連する宛先が得られないまま置き去りにされる可能性がある。この結果、生産性が低下し、ブラウズの効率も低下し、ブラウズの体験全体が苛立たしくなる。]
課題を解決するための手段

[0003] [0003] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために用いることも意図していない。]
[0004] [0004] 種々の実施形態は、ユーザーがテキストをブラウザーのアドレス・バーに入力し始めたときに、ユーザーの意図する宛先の確度に関して経験に基づく推測を行うために関連性アルゴリズムを採用したウェブ・ブラウザーを提供する。１つ又は複数の実施形態では、関連性アルゴリズムが、種々のパラメータを用い、これらのパラメータに重みを指定して、ユーザーに提供する提案の集合体に到達する。種々の規則、関連する重み付け、および関連性アルゴリズムを用いることにより、ユーザーのナビゲーション活動をし易くするために、関連提案をユーザーに提供することができる。]
図面の簡単な説明

[0005] [0005] 図面全体を通じて、同様の機構を指すために同じ番号を用いることとする。
図１は、ウェブ・ブラウザー・ユーザー・インターフェースの一部を示す。
図２は、本明細書において記載する種々の原理を、１つ又は複数の実施形態にしたがって用いることができる動作環境を示す。
図３は、１つ又は複数の実施形態による方法におけるステップを記載する流れ図である。
図４は、１つ又は複数の実施形態によるシステムの一例を示す。
図５は、１つ又は複数の実施形態による方法におけるステップを記載する流れ図である。
図６は、１つ又は複数の実施形態によるウェブ・ブラウザー・ユーザー・インターフェースの一部を示す。
図７は、１つ又は複数の実施形態による方法におけるステップを記載する流れ図である。
図８は、１つ又は複数の実施形態を実現するために用いることができるシステムの一例を示す。] 図１ 図２ 図３ 図４ 図５ 図６ 図７ 図８
実施例

[0006] 全体像
[0014] 種々の実施形態は、ユーザーがテキストをブラウザーのアドレス・バーに入力し始めたときに、ユーザーの意図する宛先の確度に関して経験に基づく推測を行うために関連性アルゴリズムを採用したウェブ・ブラウザーを提供する。１つ又は複数の実施形態では、関連性アルゴリズムは、種々のパラメータを用い、これらのパラメータに重みを指定して、ユーザーに提供する提案の集合体に到達する。種々の規則、関連する重み付け、および関連性アルゴリズムを用いることにより、ユーザーのナビゲーション活動をし易くするために、関連提案をユーザーに提供することができる。本明細書において用いる場合、「宛先」とは、限定ではない一例として、ユーザーが訪問しようとしている宛先を含むことは理解できよう。宛先は、ウェブ・サイト、ＲＳＳフィード等を含むことができる。]
[0007] [0015] 以下に続く論述では、「動作環境」と題する章が設けられており、１つ又は複数の実施形態を採用することができる一環境について説明する。これに続いて、「関連性の全体像」と題する章および関連する副章において、関連性の全体像を規定する。これは、その観念が、記載する実施形態に関連するからである。次に、「実施態様例」と題する章および関連する副章が、１つ又は複数の実施形態にしたがって採用することができる実施態様の一例を提示する。最後に、「システム例」と題する章が提示され、本明細書に記載する種々の実施形態を実現するために用いることができるシステム例について説明する。
動作環境
[0016]図２は、全体的に２００で示す、１つ又は複数の実施形態による動作環境を示す。環境２００は、１つ又は複数のプロセッサー２０４、１つ又は複数のコンピューター読み取り可能媒体２０６、および１つ又は複数のアプリケーション２０８を有する計算機２０２を含み、アプリケーション２０８は、コンピューター読み取り可能媒体上に位置し、プロセッサー（１つまたは複数）によって実行可能である。コンピューター読み取り可能媒体は、限定ではなく一例として、通例計算機に付随する揮発性および不揮発性メモリおよび／または記憶媒体のあらゆる形態を含むことができる。このような媒体は、ＲＯＭ、ＲＡＭ、フラッシュ・メモリ、ハード・ディスク、リムーバブル媒体等を含むことができる。計算機の具体的な一例については、以下で図８において図示および説明する。] 図２ 図８
[0008] [0017] 加えて、計算機２０２は、ウェブ・ブラウザー２１０の形態としてソフトウェア・アプリケーションを含む。適したウェブ・ブラウザーであればいずれでも用いることができ、その例は、本文書の譲受人およびその他から入手可能である。少なくとも一部の実施形態では、ウェブ・ブラウザー２１０は、ユーザーがテキストをブラウザーのアドレス・バーに入力し始めると、ユーザーの意図する宛先の確度に関して、経験に基づく推測を行うために関連性アルゴリズムを採用するように構成されている。１つ又は複数の実施形態では、関連性アルゴリズムは、種々のパラメータを用い、これらのパラメータに重みを指定して、ユーザーに提供する提案の集合体に到達する。種々の規則、関連する重み付け、および関連性アルゴリズムを用いることにより、ユーザーのナビゲーション活動をし易くするために、関連する提案をユーザーに提供することができる。このために、ウェブ・ブラウザーは、関連性エンジン２１１を含むか、またそうでなければこれにアクセスすることができる。関連性エンジン２１１は、先にそして以下で説明する関連性アルゴリズム（１つまたは複数）を採用する。少なくとも一部の実施形態では、関連性アルゴリズムは、ＵＲＬ、タイトル、およびコンテンツに関するストリング照合、ならびに訪問の頻度、最後の訪問以来の時間、およびユーザーに１組の提案を生成する前にユーザーがそのサイトと相互作用を行ったことがあるか否かの組み合わせというようなエレメントを組み合わせることができる。]
[0009] [0018] 加えて、環境２００は、インターネットのようなネットワーク２１２、およびコンテンツを受信および送信する１つ又は複数のウェブ・サイト２１４を含む。]
[0010] [0019]計算機２０２は、限定ではない一例として、デスクトップ・コンピューター、携帯用コンピューター、パーソナル・ディジタル・アシスタント（ＰＤＡ）のようなハンドヘルド・コンピューター、セル・フォン等のような、適した計算機であればいずれとしても具現化することができる。
関連性の全体像
[0020] 種々の実施形態において、ウェブ・ブラウザーによってアクセスすることができる特定の項目の関連性を、これらの項目と関連があり全体を通じて「メタデータ」とも呼ばれるパラメータ、およびこれらのパラメータに割り当てることができる重みに基づいて計算することができる。項目と関連付けられた加重パラメータを処理し、次いでユーザーに提示する提案の集合体を生成するために、関連性アルゴリズムが用いられる。]
[0011] [0021] １つ又は複数の実施形態では、提案の集合体は、ユーザーがある種の行為を行って宛先までナビゲートしたいことを示したときに、これに応答してユーザーに提示することができる。例えば、少なくとも一部の実施形態では、ユーザーが、ウェブ・ブラウザーの一部をなすアドレス・バーにテキスト・ストリングを入力すると、提案の集合体をユーザーに提示することができる。これらの提案は、ユーザーがテキストを更に入力するに連れて、動的に変化することができる。あるいはまたは加えて、提案の集合体は、ユーザー・インターフェース・エレメントをクリックしてアドレス・バーのドロップ・ダウン・メニューにアクセスするというような、他の何らかの行為をユーザーが行ったときに、ユーザーに提示することもできる。したがって、実施形態によっては、収集した提案が、ユーザーが実際に入力しているテキスト情報に基づいて、ユーザーに提示される場合もある。更に、他の実施形態では、収集した提案は、ユーザーが実際にテキスト情報を入力したか否かとは関係なく、ユーザーに提示される。]
[0012] [0022] １つ又は複数の実施形態では、種々のパラメータを用いることができ、ユーザーがブラウズする可能性がある項目と関連付けることができる。これらのパラメータは、重み付けすることができ、関連性アルゴリズムによって処理して、提案の集合体をユーザーに提供することができる。このようなパラメータは、限定ではなく一例として、項目と関連のあるタイトルまたはカスタム・タイトル(custom title)、項目と関連のあるＵＲＬ、特定の項目が訪問された最後の日付、これまでに項目が訪問された頻度、そしてユーザーがリストからその項目を選択したか否かを含むことができる。これらの各々について、以下で更に詳細に論ずることにする。
タイトルまたはカスタム・タイトル
[0023] ある場合には、ユーザーが入力したテキストが、ユーザーが過去にブラウズしたことがある特定のウェブページのタイトルのような、項目のタイトルと一致する場合、この項目には、ユーザーが入力したテキストと一致しないタイトルの項目よりも重く重み付けすることができる。同様に、ユーザーが、ユーザーのお気に入り項目におけるような、特定の項目にカスタム・タイトルを指定している場合、この項目は、カスタム・タイトルがない項目よりも重く重み付けすることができる。
ＵＲＬ
[0024] １つ又は複数の実施形態では、ユーザーが入力したテキストが、ユーザーが過去にブラウズしたことがある項目と関連のあるＵＲＬのある部分と一致した場合、この項目は、ユーザーが入力したテキストと一致しないＵＲＬを有する項目よりも重く重み付けすることができる。更に、少なくとも一部の実施形態では、ＵＲＬのどの部分が、ユーザーが入力したテキストと一致するかに応じて、重みを割り当てることもできる。例えば、ＵＲＬのドメインがユーザーのテキストと一致する場合、ＵＲＬのパスがユーザーのテキストと一致する場合よりも重く重み付けすることができる。このように、ＵＲＬのどの部分がユーザーのテキストと一致するかに応じて、重みをしかるべく割り当てることができる。これをどのようにすると行うことができるかの一例を、「実施態様例」と題する章において以下で紹介する。
項目が訪問された最後の日付
[0025] １つ又は複数の実施形態では、最近訪問されたことがある項目には、最近訪問されていない項目よりも重く重み付けすることができる。ここでは、ユーザーが最近あるサイトを訪問し、そのサイトのある部分と一致するテキストをタイプ入力し始めた場合、この最近訪問されたサイトは、ユーザーにとって何らかの重要性があると思われると仮定する。
項目が訪問された頻度
[0026] １つ又は複数の実施形態において、頻繁に訪問されたことがある項目には、頻繁に訪問されたことがない項目よりも重く重み付けすることができる。ここでは、ユーザーが特定のサイトに定期的に訪問し、そのサイトのある部分と一致するテキストをタイプ入力し始めた場合、その頻繁に訪問されるサイトがユーザーにとって何らかの重要性があると思われると仮定する。
リストからの選択
[0027] １つ又は複数の実施形態において、リストから特定の項目が選択された場合、特定のリストから選択されたことがない項目よりも、その項目には重く重み付けすることができる。例えば、項目を選択することができる１つのリストは、アドレス・バーのドロップ・ダウン・メニューの一部として現れるリストである。過去において、ユーザーが、アドレス・バーのドロップ・ダウン・メニューにおける提案として提示された特定の項目を選択したことがある場合もあり得る。その場合、ユーザーに対する重要性は明白であるので、その項目に関連のある重みが増大されている可能性がある。そして、ユーザーがこの項目の少なくとも一部と一致するテキストを次回入力したときに、この項目は、ユーザーに提示される提案の集合体において、前よりも高い位置に現れるようにするとよい。]
[0013] [0028] 更に別のパラメータも、関連性計算において維持し利用することができる。このような別のパラメータには、限定ではなく一例として、項目を最後に変更した日付、読まれていないカウント、ユーザーがストリング全体をタイプ入力したか否か、ユーザーがどのようにページと相互作用したか、タグまたはキー・ワード、および／または項目がフル・テキスト検索において用いられたか否かが含まれる。これらのパラメータの各々について、以下で更に詳しく調べる。
項目が最後に修正された日付
[0029] １つ又は複数の実施形態では、特定の項目が最後に変更された日付は、その項目に重みを指定する際に用いることができる。これは、特に、ＲＳＳフィードのコンテキストでは有用となることができる。ここでは、ユーザーが最近ＲＳＳフィードを更新した場合、そのＲＳＳフィードは、それよりも後に更新されていないフィードよりも、ユーザーにとって一層関連があり得ると仮定する。したがって、ユーザーが入力したテキストが、何らかの方法で、最近更新されたことがあるＲＳＳフィードと一致した場合、ユーザーに提供される提案の集合体において現れる位置を高くするとよい。
読まれていないカウント
[0030] １つ又は複数の実施形態では、いわゆる読まれていないカウントを関連性アルゴリズムによって用いることができる。例えば、少なくとも一部の実施形態では、読まれていない項目を有するＲＳＳフィードは、読まれていない項目がないＲＳＳフィードよりも上または下にランク付けすることができる。
ユーザーがストリング全体をタイプ入力したか否か
[0031] １つ又は複数の実施形態では、ユーザーがストリング全体をタイプ入力したか否かを、特定の項目に重みを指定するために用いることができる。具体的には、ユーザーが検索を行うためにテキスト・ストリング全体をタイプ入力した場合、この項目は、テキスト・ストリング全体を構成しなかった他の用語よりも重要でありユーザーにとって関連がある可能性が高いと仮定する。例えば、ユーザーがテキスト・ストリング全体をタイプ入力した場合、ユーザーは、何らかの理由で、このテキスト・ストリングと関連のある項目に非常に特別に関心があると想定することができる。この場合、この特定のテキスト・ストリングには、ユーザーが完全にタイプ入力しなかった他のテキスト・ストリングよりも高い重みを割り当てることができる。
どのようにしてユーザーがページと相互作用をおこなったか
[0032] １つ又は複数の実施形態では、ユーザーが特定のページと相互作用を行った態様を考慮に入れて、特定の項目に対する重みを割り当てることができる。ユーザーは、多くの異なる方法でページと相互作用を行うことができる。ユーザーが特定のページと相互作用を行ったという事実に基づいて、ユーザーがそのページに関心があるまたは関心があったと想定することができる。例えば、ユーザーが特定のパスワードまたはクレジット・カード番号を特定ページにタイプ入力したことがあるという場合もある。このような場合、このページの関連性は、しかるべき重みを割り当てることによって高めることができる。あるいはまたは加えて、ユーザーがあるページの特定のリンク上でクリックし、あるページ上である種の書式記入動作を行い、ページを印刷し、ページを電子メールで送り、そのページをお気に入りに追加する、あるいは多数のページのドメイン集合(domain grouping)に作用する何らかの行為を行うことができる（例えば、多数のページにわたって製品および特定の製品についての意見を探す）。このような場合、このようなページの関連性は、しかるべき重みをこれらのページに割り当てることによって、高めることができる。
タグまたはキー・ワード
[0033] １つ又は複数の実施形態では、ユーザーがタグまたはキー・ワードを特定の項目に割り当てていることもあり得る。例えば、ユーザーは、「google」に対して「goo」のような検索タグを用いる場合もある。このような場合、ユーザーが次回「goo」とタイプ入力したときに、「google」を奨励するように、しかるべき重みを割り当てることによって「google」の関連性を高めることができる。]
[0014] [0034] 加えて、ユーザーが特定の検索タームを用いて検索を行う場合、ユーザーが訪問したことがある到達ページを、その特定の到達ページを表す検索タームと結び付けることができる。これに基づいて、ユーザーが再度その検索タームをタイプ入力した場合、到達ページの関連性は、しかるべき重みをそれに割り当てることによって、高めることができる。
タームがフル・テキスト検索において用いられたか否か
[0035] ユーザーが特定のタームを用いて特定のページの検索を行うとき、ユーザーに戻されユーザーによって訪問されるページにインデックスを付けることができる。つまり、戻される１つまたは複数のページの内容にインデックスを付けて、今後の検索において項目を戻すために用いることができる。具体的には、ユーザーが「STIHL 3000」という用語を検索し、この検索に応答して４つのページを訪問した場合、これら４つのページの内容にインデックスを付けることができ、ユーザーが今後同じタームを検索する場合に、これらのページを提案の集合体においてユーザーに提示できるようにする。]
[0015] [0036]図３は、１つ又は複数の実施形態による方法におけるステップを記述する流れ図である。この方法は、適したハードウェア、ソフトウェア、ファームウェア、またはその組み合わせであればそのいずれとでも実現することができる。少なくとも一部の実施形態では、本方法の態様は、適切に構成されたウェブ・ブラウザーのようなアプリケーションによって実現することができる。] 図３
[0016] [0037] ステップ３００では、ブラウザーがアクセス可能なタームと関連のあるメタデータを維持する。メタデータは、相応しい方法であればそのいずれでも維持することができる。例えば、クライアント・デバイス上に維持されているローカル・メタデータ・ストアに、メタデータを維持することができる。あるいはまたは加えて、リモート・メタデータ・ストアにメタデータを維持することもできる。加えて、いずれかの適した方法で、メタデータにインデックスを付けることもできる。ステップ３０２において、重みをメタデータに割り当てる。重みは、適した方法であればそのいずれでも、そして適した割り当てであればそのいずれを用いても、割り当てることができる。重みを割り当てる際に考慮に入れることができるプロパティの例は、先に記載しており、更に「実施態様例」と題する章において後ほど説明する。ステップ３０４では、関連性アルゴリズムを用いて、重み付けしたメタデータを処理する。適した関連性アルゴリズムであればそのいずれでも用いることができ、以下でその一例を示す。]
[0017] [0038] ステップ３０６では、１つ又は複数の項目のアクセスと関連のあるユーザーの行為を受ける。適したユーザー行為であればいずれでも用いることができる。例えば、少なくとも一部の実施形態では、ユーザー行為は、ウェブ・ブラウザーに付随するアドレス・バーに、該当するテキストをタイプ入力することを含むことができる。あるいはまたは加えて、ユーザー行為は、該当するテキストをタイプ入力すること以外でも可能である。例えば、少なくとも一部の実施形態では、ユーザー行為は、ブラウザーのアドレス・バーと合わせて提示されるような、ドロップ・ダウン・メニューにアクセスすることを含むことができる。ユーザー行為を受けたことに応答して、ステップ３０８では、このユーザー行為および関連性アルゴリズムの出力に基づいて、１つ又は複数の提案を提示する。]
[0018] [0039] 種々の実施形態では、ユーザーに提示する提案は、関連性アルゴリズムによって計算した関連性にしたがってランク付けされている項目を含むことができる。提案は、単調な提案のリストとして提示することができる。あるいはまたは加えて、ユーザーにとって関心があると思われる様々なタイプ(type)にしたがって、提案を提示または分類することもできる。例えば、ユーザーがウェブ・ブラウザーを用いて種々のタイプの項目にアクセスすることができる。タイプの例には、限定ではなく一例として、履歴タイプ、お気に入りタイプ、フィード・タイプ、および／またはタイプ入力タイプが含まれる。]
[0019] [0040]履歴タイプは、ユーザーのブラウズ履歴に現れる項目を含む。お気に入りタイプは、ユーザーのお気に入りリストに現れる項目を含む。フィード・タイプは、ＲＳＳフィードのような、ユーザーがアクセスすることができるフィードを含む。このようなフィードは、ユーザーが予約したことがあるまたはその他の方法で消費したことがあるＲＳＳフィードのリストに現れる場合もある。タイプ入力タイプは、アドレス・バー等のような、該当するユーザー・インターフェース・エレメントにユーザーがタイプ入力したことがある項目を含むことができる。]
[0020] [0041] ここで、前述した原理、および実施態様例に更に一般的に関連するその他の原理を用いて、具体的な実施態様について説明する実施態様例について検討する。
実施態様例
[0042] 以下の論述では、各データの関連性を判断するために用いられるルール・セットを含む、ユーザーに関連データを提示するメカニズム、およびルール・セットを内部で調整する方法について説明する実施態様例を示すが、これは一例に過ぎない。]
[0021] [0043] 「関連性」という用語は、インターネットをブラウズするという文脈では、所与のナビゲーション・クエリーに対して、ウェブサイトがどのように関連するのか、接続されているのか、または該当するのかを記述するために用いられる。ユーザーがあるテキストをブラウザーに入力し始めるときに、彼らがナビゲートしようとしている正確な宛先を知ることは困難である。他方、彼らの宛先の確度に関して、経験に基づく推測を行うことは可能である。これは、ユーザーの宛先に特定して格納されているメタデータに値を適用することによって、遂行することができる。以下の論述では、前述のメタデータに適用することができる種々のルールおよびアルゴリズムについて説明する。メタデータは、このように、前述の関連性メカニズムを構成する。]
[0022] [0044]ユーザーに関連のある提案または結果を提供することにより、ユーザーは、格段に少ないユーザー行為で宛先までナビゲートすることが可能となり、彼らの宛先を素早く発見する際にこれらを信頼することが可能になる。また、ユーザー行為を最小限に抑えることによって、ユーザーの生産性も増大させることができ、ウェブサイトを再訪問し、ユーザーに一層興味の尽きないブラウズ体験を提供することに注意を向けると、効率を高めることができる。一例として、本発明の技法を提供することができる以下の想定場面について考える。アビ(Abby)は、彼女のウェブ・ブラウザーを開き、アドレス・バー上でクリックして、最初の５つの履歴、お気に入り、およりＲＳＳフィードが戻された。これらは、以下のように関連性が判断され、その関連性に関してランク付けされている。次いで、アビは、彼女のお気に入りには存在しないウェブサイト・アドレスをタイプ入力する。このウェブサイトと一致するクエリーを彼女が次回入力するときには、その関連性が高くなり、したがってリスト上では今よりも高い位置に現れる可能性がある。ここで、アビは彼女のブラウザーの履歴を消去することを決定する。彼女がそれを行った後にあるクエリーをタイプ入力し始めると、彼女は、彼女のお気に入りおよびＲＳＳフィードについての関連結果は戻されるが、履歴結果は戻されないことが分かる。次いで、アビはアドレス・バーにタイプ入力し始める。彼女は、彼女が文字をタイプ入力する程、結果は関連が一層深くなることに気が付く。ここで、アビはあるクエリーをアドレス・バーにタイプ入力し、彼女が二度と見たくない宛先を、ドロップ・ダウン・リストにおいて見る。彼女はドロップ・ダウン・リストからそれを削除し、以後同じクエリーが入力されても、その宛先はもはや現れなくなる。即ち、彼女が取った行為に基づいて、その関連性は降格させられたのである。以上から認められようが、これまでに記載しそして以下に記載する本発明の技法を用いることにより、これらおよびその他の想定場面を提示することができる。]
[0023] [0045] 図示し説明した実施形態では、結果即ち提案が戻され、これらを異なるタイプにしたがって分類することができる。提案を分類することができる様々なタイプの一例に過ぎないが、タイプには、タイプ入力したＵＲＬ、履歴、お気に入り、およびＲＳＳフィードを含むことができる。勿論、特許請求する主題の主旨および範囲から逸脱することなく、その他のタイプも用いることができる。]
[0024] [0046]図４は、１つ又は複数の実施形態によるシステム例を示す。この例では、システムは、ユーザー・インターフェース４００、単語分解コンポーネント４０４を有するデータ・モデル４０２、１つ又は複数のデータ・プロバイダー４０６、４０８、および４１０、ならびに１つ又は複数の付随するデータ・ストア４１２、４１４、および４１６を含む。図示し説明する実施形態では、ユーザー・インターフェース４００は、ウェブ・ブラウザーによって提供され、ユーザー・インターフェースの一部として、アドレス・バーを含み、ここにユーザーがクエリーをタイプ入力することができる。] 図４
[0025] [0047]ユーザーがユーザー・インターフェース４００を通じてクエリーを入力すると、関連のあるクエリー・ストリングがデータ・モデル４０２に供給される。単語分解コンポーネント４０４はユーザーのクエリーを単語に分解し、分解したクエリーをデータ・プロバイダー４０６、４０８、および４１０の１つ又は複数に配信する。次いで、データ・プロバイダーは、項目、およびユーザーのブラウズ活動と関連のある種々の項目メタデータというような、インデックス化された情報を含む、種々のデータ・ストアに問い合わせるために用いることができるクエリーを形成する。メタデータの例は、これまでにそしてこの後にも提示する。１つ又は複数の実施形態では、データ・プロバイダーは、関連性ルール・セットおよび／またはアルゴリズム（１つまたは複数）と関連のある具体的な情報を利用して、そのクエリーを定式化するする。]
[0026] [0048] 次に、データ・プロバイダーによって定式化された１つまたは複数のクエリーを実行し、クエリーの単語をストリング・メタデータと照合し、次いでメタデータの重みの関連性に基づいて結果をソートすることによって、該当する結果を選別する。メタデータおよびメタデータの重みの例は、以下で直ちに提示する。結果を選別しソートした後、ユーザー・インターフェース４００を通じてユーザーに表示するために、結果リストがデータ・プロバイダーによって戻される。ユーザー・インターフェースの一例は、以下で図６において示される。] 図６
[0027] [0049]図５は、１つ又は複数の実施形態による方法におけるステップを記述する流れ図である。この方法は、適したハードウェア、ソフトウェア、ファームウェア、またはその組み合わせであればそのいずれとでも実現することができる。少なくとも一部の実施形態では、本方法の態様は、適切に構成されたウェブ・ブラウザーのようなアプリケーションによって実現することができる。] 図５
[0028] [0050] ステップ５００では、タイプ入力されたクエリー・ストリングを受け取る。このステップは、ユーザーがクエリー・ストリングを、ウェブ・ブラウザーの一部をなすアドレス・バーのような、適したユーザー・インターフェース・エレメントにタイプ入力したときに実行することができる。ステップ５０２において、このクエリー・ストリングをデータ・モデルに供給する。ステップ５０４において、クエリー・ストリングを単語に分解する。ステップ５０６において、分解したクエリー・ストリングを用いて、クエリーを定式化する。ステップ５０８において、クエリーを実行し、ステップ５１０において、ユーザーに表示するためにクエリー結果を戻す。]
[0029] [0051]図６は、全体的に６００で示す、１つ又は複数の実施形態によるブラウザーのユーザー・インターフェースの一部を示す。この例では、ユーザー・インターフェース６００は、クエリー・ストリングをタイプ入力することができるアドレス・バー６０２と、付随するドロップ・ダウン・メニュー６０４とを含む。ドロップ・ダウン・メニュー６０４は、以上および以下で記載する関連性アルゴリズムに基づいて算定した種々の提案をユーザーに表示する。尚、この例では、種々の提案を異なるタイプにしたがって分類できることを注記しておく。具体的に、この特定的な例では、限定ではなく一例として、タイプには、タイプ入力したＵＲＬ、履歴、お気に入り、およびＲＳＳフィードが含まれる。勿論、特許請求する主題の主旨および範囲から逸脱することなく、その他のタイプも用いることができる。] 図６
[0030] [0052] １つ又は複数の実施形態にしたがって用いることができるシステム、方法、およびユーザー・インターフェースの概略的な全体像について検討したので、これより前述した実施形態にしたがって利用することができる一部の実施態様例の詳細について検討する。尚、以下で直ちに説明する実施態様の詳細は、単なる例に過ぎないことを意図していることは認められようし、言うまでもないことである。したがって、実施態様の詳細における変形も、特許請求する主題の主旨および範囲から逸脱することなく、行うことができる。
単語分解の例
[0053] １つ又は複数の実施形態では、ユーザーのクエリー・ストリングおよび宛先のストリング・メタデータの双方を単語に分解する。前述の例では、これは、図４における単語分解コンポーネント４０４によって処理される。この例では、句読点の形態を空間に変換することによって単語が区切られている。例えば、以下の入力ＵＲＬおよび結果的に得られた単語の集合について検討する。] 図４
[0031] ]
[0032] [0054] この例では、白空間で分離されたキャラクタの各ストリングが単語と見なされ、次いで、前に付けられ(prefixed)ユーザーのクエリー単語と照合される。尚、サブドメインも単語に分解されることを注記しておく。
宛先メタデータ
[0055] 図示し説明した実施形態では、宛先をインデックス化し、インデックス化されるものには、履歴、お気に入り、およびＲＳＳフィードが含まれる。適したインデックス化方式であればいずれでも利用することができる。タイプ入力したＵＲＬは、インデックス化してもしなくてもよい。タイプ入力したＵＲＬをインデックス化しない場合、これらには単語分解が行われず、ユーザーのクエリー・ストリングとプレフィックスの照合が行われる。
ウェブページ特定メタデータ
[0056] １つ又は複数の実施形態では、ユーザーが入力した単語を分解し、ＵＲＬメタデータの別々の断片と照合する。宛先のＵＲＬは、重みを適用することによって、その重要性を指定するために、異なるセクションに分解される。ユーザーが以前に訪問したことがある以下の２つのＵＲＬについて検討する。]
[0033] http://www.host.com/path/and.htm?="query+query2"
htttp://website.internet.org/path1/longlongpath2/index.html?="search+query"
１）プロトコルが取り去られたＵＲＬ（下線部）
ａ．１単語ユーザー・クエリーとＵＲＬとの間でプレフィックスの照合を行うために、これを保存する。
２）ホスト名称（太字の下線部）
ａ．ホストのみに対して単語分解を行うために、これを保存する。]
[0034] ｂ．上位ドメインは、ユーザー・クエリーとの照合のためには保存されない。
３）残りのパスおよびクエリー・ストリング（太字でない下線部）
ａ．パスおよびクエリーのみに対して単語分解を行うために、これを保存する。
４）プロトコル自体
ａ．ユーザーは、プロトコル：ＦＴＰまたはＨＴＴＰを入力することによって、特定のサイトを検索することができる。]
[0035] ｉ．ＨＴＴＰはＨＴＴＰＳと一致するが、全く逆ではない。]
[0036] [0057] 以下の表は、宛先毎に記録されるストリング・メタデータの概要を示す。
履歴特定メタデータ]
[0037] ]
[0038] [0058] １つ又は複数の実施形態では、履歴宛先について、ＵＲＬのホストが最高の重要性を有する。何故なら、これはＵＲＬの中で最も容易に認識できるからである。ページ・タイトルは、ＵＲＬよりも重要性は低い。
お気に入り特定メタデータ]
[0039] ]
[0040] [0059] お気に入りの宛先については、ユーザーがお気に入りに与えた名称は、ＵＲＬに優先して最も高い重要度を有する。殆どの場合、ユーザーはお気に入り毎に自分自身の名前を供給するので、これは一般に、メタデータの中でも最も認識し易い断片である。フォルダ・パスは、例えば、ユーザーが１組のお気に入りを、作成したフォルダ、例えば、「ディノザウルス」に入れたときに用いられる。ユーザーが「ディノザウルス」をアドレス・バーにタイプ入力すると、特定のお気に入りが単語「ディノザウルス」を含まなくても、そのフォルダにおけるお気に入りが、関連性を計算した結果に含まれる。
ＲＳＳフィード特定メタデータ]
[0041] ]
[0042] [0060]フィード・タイトルおよびフィード名称は、ＲＳＳフィードについて最も高い重要度を保持する。個々のフィード項目のタイトル、内容、および著者は、最上位フィードのタイトルおよび名称よりも低い重要性を保持する。]
[0043] [0061] 以下の表は、プレフィックスの照合を利用しない場合に、ユーザーがアドレス・バーにタイプ入力したときにおける入力および照合結果を記述する。一例のために、ストリングは、その分解されない形態のまま残されている。ユーザー・クエリー単語の一致が強調されている。最初の表は、単語分解に用いられるインデックス列の一例を一覧にして示し、２番目の表は、ユーザーの入力およびヒットしたサイトの例を一覧にして示す。]
[0044] ]
[0045] ]
[0046] 過去のブラウズ・メタデータ
[0062] 以下の表は、各宛先に特定的な、過去のブラウズ・メタデータの概要を示す。１つ又は複数の実施形態では、維持される過去のブラウズ・メタデータには、訪問回数および選択が含まれる。]
[0047] [0063]訪問回数は、サイトの関連性において決定論的である。ユーザーがサイトを訪問する回数が多い程、所与のクエリーに対する関連性が高くなる。選択は、アドレス・バーのような、リストから選択される回数が多い程、結果の関連性を高めることができるので重要である。アドレス・バーから選択される回数が多い程、ユーザーにとって一層重要となる。したがって、提案の中において選択を促進することができる。]
[0048] [0064]履歴結果は、訪問回数を、アドレス・バーから項目が選択された回数と共に追跡する。お気に入りに関して、１つ又は複数の実施形態では、選択の数を追跡する。このようなことを、以下の表に明記する。
履歴]
[0049] ]
[0050] [0065] 宛先について、特定のウェブサイトへの訪問回数は、アドレス・バーにおいてそれが選択された回数と共に、その関連性を判断するのに役立つ。
お気に入り]
[0051] ]
[0052] [0066] お気に入りについて、１つ又は複数の実施形態では、訪問回数は、同じＵＲＬの履歴における宛先に直接結ばれている。したがって、少なくとも一部の実施形態では、グループ間の関連性がないので、訪問回数は考慮されない。
ＲＳＳフィード]
[0053] ]
[0054] [0067] 宛先について、特定のＲＳＳフィードへの訪問回数は、アドレス・バーにおいてそれが選択された回数と共に、その関連性を判断するのに役立つ。]
[0055] [0068]ユーザーの履歴を追跡するために維持されているインデックスの中に存在しないウェブサイトにユーザーがナビゲートした場合、新たなエントリが作成される。次いで、新たなウェブサイトが、ＩＵＲＩ特定のＵＲＬデータと共にインデックスに追加される。加えて、訪問回数および選択が次にデフォルト値に設定される。]
[0056] [0069]インデックスの中に存在しないウェブサイトにユーザーがナビゲートした場合、データ・プロバイダーは、宛先についてのメタデータを更新するためにクエリーを発生する。]
[0057] [0070] 以下の表は、特定のメタデータ・コラムの内どれが、そのような影響を受けるか、概要を示す。]
[0058] ]
[0059] 重み
[0071] 以下の表は、１つ又は複数の実施形態にしたがって、宛先のメタデータに適用される重みの概要を示す。個々の重み値は、各メタデータが、宛先のメタデータの全ての総合関連性に対して、どのくらい重要であるかを表す。]
[0060] [0072] 例えば、抜き取られたＵＲＬ（．５０）、訪問回数（．３５）、および選択（．１５）の列が、結果の関連性を決定するために考慮されていたと仮定する。メタデータの総合関連性は、１．００に等しい。つまり、重みが．５０である「抜き取られたＵＲＬ」は、結果の総合関連性の内半分（．５０／１．００）を決定することになる。]
[0061] [0073] 各メタデータ列の重みに用いられる値は、適した方法であればいずれでも割り当てることができる。例えば、少なくとも一部の実施形態では、研究を行うことができ、メタデータの内どの断片が他の断片よりも重要であるか提案するために、データを収集することができる。加えて、変化するフィードバックおよび重要性に適応するために、値を調節することができる。
履歴]
[0062] ]
[0063] [0074] １つ又は複数の実施形態では、履歴宛先のホスト名称が最高の重要性を保持する。何故なら、ユーザーは、ＵＲＬの最初からタイプ入力することによって、宛先を見つけるように訓練されている傾向があるからである。ページ・タイトルは、履歴宛先内において２番目に認識可能なストリングであるが、ユーザーがページ・タイトルをタイプ入力して結果を得るのに慣れていないので、重要性は多少低く見なされる。このため、ユーザーが何故結果が現れているのか理解するに連れて、結果の予測可能性が高くなる。]
[0064] [0075] 宛先に対する訪問回数は、宛先の関連性に大きく影響する。何故なら、ユーザーがサイトを訪問する程、そのサイトが所与のクエリーに関連する確率が高くなるからである。
お気に入り]
[0065] ]
[0066] [0076] １つ又は複数の実施形態では、お気に入りの宛先の名称は最高の重要性を保持する。何故なら、これは旧来の自動補完(legacy auto-complete)において一致しており、ユーザーによって定められるのが一般的であるからである。ＵＲＬは、履歴における場合と同じ重要性を保持するが、訪問回数によって相殺(offset)されることはない。
ＲＳＳフィードおよびフィード項目]
[0067] ]
[0068] [0077]ユーザーは、何を検索しているのかに応じて、ＲＳＳフィードおよびそのフィード項目双方全域を検索するので、フィード・メタデータおよびフィード項目メタデータ双方が考慮される。最も認識可能なストリングは、フィードおよびフィード項目の場合、フィード・タイトル、フィード名称、および項目タイトルである。
関連性ルール・セット
[0078] 以下の論述では、１つ又は複数の実施形態にしたがって結果の関連性を判断するためのルールおよび概念について説明する。１つ又は複数の実施形態によれば、検索クエリーを入力するときにユーザーが用いることができる２つの異なる「マインド・セット」(mind set)がある。これらは、確信(confident)マインドセットおよび検索マインドセットであり、以下各々について別個に説明する。
確信マインドセット
[0079] 確信マインドセットを用いる場合、検索によって正確なＵＲＬ一致が得られる。確信マインドセットにおける場合、クエリーは一般に以下の特性を有する。最初に、クエリーは１つの単語であることが一般的である。加えて、クエリーは、一般に、以下の体系のプレフィックスで開始する。http://、http://wwww.、https://、https://www.、www.、ftp://、file:。更に、クエリーは、一般に、ホスト名称で始まり、その後に最上位のドメインが続き、そしてＵＲＬの残り、例えば、google.com、cnn.com/TECH、およびrit.edu/infocenter/student/htmがある場合もある。
検索マインドセット
[0080] 検索マインドセットを用いる場合、以上および以下で説明したように、単語分解を行う。検索マインドセットにおける場合、クエリーは、一般に、次の特性を有する。最初に、クエリーは２つ以上の単語であることが一般的である。加えて、クエリーは、一般に、プロトコルのプレフィックスで開始しない。更に、クエリーは、一般にホスト名称で開始するが、最上位ドメインではない。]
[0069] [0081] この情報に基づいて、「確信マインドセット」および「検索マインドセット」と呼ばれる２つの方法の内の１つを用いて結果を戻すことが可能である。各方法は、関連性を計算するために、ストリング照合方法を、メタデータの一意の集合の選択と共に実行する。なお、双方の方法は、先に概説したように、該当するメタデータ列（例えば、訪問回数および選択）でランク付けすることによって、結果をソートすることは認められよう。]
[0070] [0082]図７は、１つ又は複数の実施形態による検索方法におけるステップを記述する流れ図である。この方法は、適したハードウェア、ソフトウェア、ファームウェア、またはその組み合わせであればそのいずれとでも実現することができる。少なくとも一部の実施形態では、本方法の態様は、適切に構成されたウェブ・ブラウザーのようなアプリケーションによって実現することができる。] 図７
[0071] [0083] ステップ７００において、ユーザーが入力したクエリーが１単語よりも多いか否か確認する。ユーザーが入力したクエリーが１単語よりも多くない場合、ステップ７０２において、ユーザーが入力したクエリーの先頭にプロトコル・ストリングおよび／またはＵＲＩが付いているか否か確認する。ユーザーが入力したクエリーの先頭にプロトコル・ストリングおよび／またはＵＲＩが付いている場合、ステップ７０４において、第１方法、この例では、確信方法を用いて、結果を戻す。ユーザーが入力したクエリーの先頭にプロトコル・ストリングおよび／またはＵＲＩが付いていない場合、ステップ７０６において、第２の異なる方法、この例では、検索方法を用いて、結果を戻す。]
[0072] [0084] 一方、ステップ７００において、ユーザーが入力したクエリーが１単語よりも多いことを確認した場合、ステップ７０６において、第２の異なる方法、この例では、検索方法を用いて、結果を戻す。]
[0073] [0085]競合方法(competent method)および検索方法双方の例を、以下に示す。
確信方法
[0086] １つ又は複数の実施形態では、確信方法が用いられるのは、ユーザーが１単語クエリーを用いており、この１単語クエリーがプロトコルのプレフィックスまたは有効なＵＲＩで始まる場合である。この方法は、以下の手法を利用する。最初に、プレフィックス・ストリングを宛先の抜き取られたＵＲＬと照合するために、全てのプロトコル・プレフィックスからクエリー単語を抜き取る。第２に、以下のメタデータ列を用いて、関連性を計算する。
履歴
・抜き取られたＵＲＬ−単語分解が全くないので、単にプレフィックスをＵＲＬと照合する。
お気に入り
・抜き取られたＵＲＬ−単語分解が全くないので、単にプレフィックスをＵＲＬと照合する。]
[0074] ＲＳＳフィードおよびフィード項目
・抜き取られたＵＲＬ−単語分解が全くないので、単にプレフィックスをＵＲＬと照合する。
・フィード・タイトル−ユーザーのクエリーがフィード・タイトルと一致する可能性がある。
・フィード名称−ユーザーのクエリーがフィード名称と一致する可能性がある。
・項目タイトル−ユーザーのクエリーが項目タイトルと一致する可能性がある。
・項目内容−ユーザーのクエリーが項目内容の内側と一致する可能性がある。
・項目著者−ユーザーのクエリーが項目の著者と一致する可能性がある。]
[0075] タイプ入力したＵＲＬ
・抜き取られたＵＲＬ−単語分解が全くないので、単にプレフィックスをＵＲＬと照合する。
検索方法
[0087] １つ又は複数の実施形態では、検索方法が用いられるのは、ユーザーが１単語のクエリーを用いており、このクエリーがプロトコルのプレフィックスや有効なＵＲＩで始まらない場合、または２単語よりも多いクエリーの場合である。この方法は、次の手法を利用する。最初に、クエリーの単語に変化を加えずに、単語分解を用いる。第２に、関連性を計算するために、以下のメタデータ列を用いる。]
[0076] 履歴
・ホスト−単語分解を用いるので、ホスト上で分解する。
・パスおよびクエリー単語分解を用いるので、パスおよびクエリーを含ませる。
・ページ・タイトル−単語分解を用いるので、ページ・タイトルを含ませる。]
[0077] お気に入り
・ホスト−単語分解を用いるので、ホスト上で分解する。
・パスおよびクエリー単語分解を用いるので、パスおよびクエリーを含ませる。
・お気に入りの名称−単語分解を用いるので、お気に入りの名称を含ませる。]
[0078] ＲＳＳフィードおよびフィード項目
・ホスト−単語分解を用いるので、ホスト上で分解する。
・パスおよびクエリー単語分解を用いるので、パスおよびクエリーを含ませる。
・フィード・タイトル−単語分解を用いるので、フィード・タイトルを含ませる。
・フィード名称−単語分解を用いるので、フィード名称を含ませる。
・項目タイトル−単語分解を用いるので、項目タイトルを含ませる。
・項目内容−単語分解を用いるので、項目内容を含ませる。
・項目著者−単語分解を用いるので、項目の著者を含ませる。]
[0079] タイプ入力したＵＲＬ
・ホスト−単語分解を用いるので、ホスト上で分解する。
・パスおよびクエリー単語分解を用いるので、パスおよびクエリーを含ませる。
[0088] １つ又は複数の実施形態では、履歴宛先のＵＲＬが単にホストおよび最上位ドメインである場合、これを非常に関連があると見なすとよい。例えば、ユーザーがクエリー「ｃｎｎ」をアドレス・バーにタイプ入力し、次の５つの結果が戻されたと仮定する。]
[0080] １．www.cnn.com/2007
２．www.cnn.com/2007/TECH
３．www.cnn.com/news/coolstory/1997.html
４．www.cnn.com
５．www.cnn.com/2007/HistoryChannel.thm]
[0081] [0089] ４番目の結果は、単にホストおよび最上位ドメインであるので、これが関連性の大きな増大を受けてしかるべきである。最上位アドレスは、ナビゲーションにとって極普通の開始点になるので、ユーザーは予測可能という意識を高めることになる。]
[0082] [0090] １つ又は複数の実施形態では、宛先は、多数のグルーピング(grouping)またはタイプに存在してもよい。宛先は、多数のグルーピングに存在してもよいが、これらのグルーピングに特定的なメタデータは一意であってもよい。]
[0083] [0091] １つ又は複数の実施形態では、グループ間関連性は適用されない。例えば、１つのグルーピングにおける宛先について存在するメタデータ、例えば履歴は、他のグルーピングに存在するかもしれない同じ宛先の関連性には影響を及ぼさない。]
[0084] [0092] １つ又は複数の実施形態では、アドレス・バーから宛先を削除すると、その関連性も削除される。即ち、ユーザーによってアドレス・バーから項目が削除されると、しかるべきストアからもそれが削除され、つまり、再度訪問されるまで、関連のある結果として戻されることができなくなる。]
[0085] [0093] １つ又は複数の実施形態では、履歴を消去すると、履歴およびタイプ入力したＵＲＬも削除され、これらのグループについての関連性も除去される。例えば、ユーザーがその履歴を削除することを決定した場合、全ての履歴およびタイプ入力したＵＲＬ宛先ならびにそれらのメタデータがインデックスから消去され、関連のある結果として戻されることができなくなる。
重みの読み出し
[0094] １つ又は複数の実施形態では、データ・プロバイダーが、インデックスから結果を読み出して順番に並べるために、しかるべきクエリー・ステートメント、例えば、ＳＱＬステートメントを構築する。
関連結果の返送
[0095] １つ又は複数の実施形態では、一旦関連性規則が関連性エンジンから入手されたなら、これらを、ＳＱＬクエリーのようなクエリーに挿入することができる。クエリーは、データ・プロバイダーによって定義され適用される。]
[0086] [0096] 一旦しかるべきストアに適用されると、クエリーは、関連性の宛先への適用、重みに応じたソート、データ・モデルが読み解く(digest)ことができるフォーマットへの、得られたデータの変換を可能にする。次いで、データは、レイヤを遡って、ユーザー・インターフェース（即ち、アドレス・バーのドロップ・ダウン・メニュー）に返送され、ここでユーザーに表示される。
システム例
[0097]図８は、先に説明した種々の実施形態を実現することができる計算機の一例８００を示す。計算機８００は、例えば、図２の計算機２０２、または適した計算機であれば他のいずれでも可能である。] 図２ 図８
[0087] [0098]計算機８００は、１つ又は複数のプロセッサーまたは演算装置８０２、１つ又は複数のメモリおよび／または記憶コンポーネント８０４、１つ又は複数の入出力（Ｉ／Ｏ）デバイス８０６、ならびにこれら種々のコンポーネントおよびデバイスが互いに通信することを可能にするバス８０８を含む。バス８０８は、様々な種類のバス構造の内いずれの１つ又は複数をも表し、メモリ・バスまたはメモリ・コントローラ、周辺バス、加速グラフィクス・ポート、およびプロセッサーまたはローカル・バスを含み、種々のバス・アーキテクチャのいずれかを用いる。バス８０８は、有線バスおよび／またはワイヤレス・バスを含むことができる。]
[0088] [0099]メモリ／記憶コンポーネント８０４は、１つ又は複数のコンピューター記憶媒体を表す。コンポーネント８０４は、揮発性媒体（ランダム・アクセス・メモリ（ＲＡＭ）のような）および／または不揮発性媒体（リード・オンリー・メモリ（ＲＯＭ）、フラッシュ・メモリ、光ディスク、磁気ディスク等のような）を含むことができる。コンポーネント８０４は、固定媒体（例えば、ＲＡＭ、ＲＯＭ、固定ハード・ドライブ等）、およびリムーバブル媒体（例えば、フラッシュ・メモリ・ドライブ、リムーバブル・ハード・ドライバ、光ドライブ等）を含むことができる。]
[0089] [00100] １つ又は複数の入出力デバイス８０６は、ユーザーがコマンドおよび情報を計算機８００に入力することを可能にし、更に情報をユーザーおよび／またはその他のコンポーネントやデバイスに提示することを可能にする。入力デバイスの例には、キーボード、カーソル制御デバイス（例えば、マウス）、マイクロフォン、スキャナ等が含まれる。出力デバイスの例には、ディスプレイ・デバイス（例えば、モニターまたはプロジェクター）、スピーカー、プリンター、ネットワーク・カード等が含まれる。]
[0090] [00101] 本明細書では、ソフトウェアまたはプログラム・モジュールという一般的な文脈において種々の技法について説明した。一般に、ソフトウェアは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含み、特定のタスクを実行するか、または特定の抽象的データ・タイプを実現する。これらのモジュールおよび技法の実施態様は、何らかの形態のコンピューター読み取り可能媒体上に格納することができ、またはそれによって送信することができる。コンピューター読み取り可能媒体は、計算機がアクセスすることができる入手可能な１つまたは複数の媒体であれば、いずれでも可能である。一例として、そして限定ではなく、コンピューター読み取り可能媒体は「コンピューター記憶媒体」を構成することができる。]
[0091] [00102] 「コンピューター記憶媒体」は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータというような情報の格納のために、あらゆる方法または技術で実現される。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル・ビデオ・ディスク（ＤＶＤ）またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができしかもコンピューターがアクセス可能なその他のいずれの媒体も含むが、これらに限定されるのではない。
結論
[00103] 種々の実施形態は、ユーザーがテキストをブラウザーのアドレス・バーに入力し始めたときに、ユーザーの意図する宛先の確度に関して経験に基づく推測を行うために関連性アルゴリズムを採用したウェブ・ブラウザーを提供する。１つ又は複数の実施形態では、関連性アルゴリズムは、種々のパラメータを用い、これらのパラメータに重みを指定して、ユーザーに提供する提案の集合体に到達する。種々の規則、関連する重み付け、および関連性アルゴリズムを用いることにより、ユーザーのナビゲーション活動をし易くするために、関連提案をユーザーに提供することができる。]
[0092] [00104] 以上、構造的特徴および／または方法論的行為に対して特定的な文言で、主題について説明したが、添付した特許請求の範囲に定義されている主題は、必ずしも前述した特定的な特徴や行為に限定されるのではない。逆に、前述した特定的な特徴および行為は、特許請求の範囲を実現する形態の例として開示したまでである。]

权利要求:

請求項1
コンピューター実装方法であって、ブラウザークセス可能項目と関連のあるメタデータを維持するステップであって、前記メタデータが、項目に付随するタイトル、項目と関連のあるＵＲＬ、ユーザーが項目を訪問した最後の日付、ユーザーが項目を訪問した頻度、および項目がリストから選択されたか否かを含む、ステップと、重みを前記メタデータに割り当てるステップと、重み付けしたメタデータを、関連性アルゴリズムを用いて処理するステップと、１つ又は複数の項目にアクセスすることに伴うユーザー行為を受けるステップと、前記ユーザー行為の受容に応答して、前記ユーザー行為および前記関連性アルゴリズムの出力に基づいて、１つ又は複数の提案を提示するステップと、を備えている、コンピューター実装方法。
請求項2
請求項１記載の方法において、前記ユーザー行為が、ウェブ・ブラウザーのユーザー・インターフェースにテキストを入力することである、方法。
請求項3
請求項２記載の方法において、前記ウェブ・ブラウザーのユーザー・インターフェースがアドレス・バーを含み、前記テキストは前記アドレス・バーにタイプ入力されている、方法。
請求項4
請求項１記載の方法において、前記ユーザー行為は、前記ウェブ・ブラウザーに付随するドロップ・ダウン・メニューにアクセスすることを含む、方法。
請求項5
請求項４記載の方法において、前記ドロップ・ダウン・メニューは、ブラウザーのアドレス・バーと共に提示される方法。
請求項6
請求項１記載の方法において、前記メタデータは、更に、項目が最後に変更された日付を含む、方法。
請求項7
請求項１記載の方法において、前記メタデータは、更に、以下の内の１つ又は複数を含む、方法。項目と関連のある未読カウント、項目と関連のあるストリング全体をユーザーがタイプ入力したか否か、ユーザーがどのようにページと相互作用したか、項目と関連のあるタグまたはキー・ワード、およびユーザーが供給した項目がフル・テキスト検索において用いられたか否か。
請求項8
コンピューター読み取り可能命令を備えている、１つ又は複数のコンピューター読み取り可能記憶媒体であって、前記コンピューター読み取り可能命令を実行すると、ブラウザークセス可能項目と関連のあるメタデータを維持するステップであって、前記メタデータが、項目に付随するタイトル、項目と関連のあるＵＲＬ、ユーザーが項目を訪問した最後の日付、ユーザーが項目を訪問した頻度、および項目がリストから選択されたか否かの内１つ又は複数を含む、ステップと、重みを前記メタデータに割り当てるステップと、重み付けしたメタデータを、関連性アルゴリズムを用いて処理するステップと、１つ又は複数の項目にアクセスすることに伴うユーザー行為を受けるステップと、前記ユーザー行為の受容に応答して、前記ユーザー行為および前記関連性アルゴリズムの出力に基づいて、提案を提示するステップであって、前記提案を異なるタイプにしたがって分類する、ステップと、を備えている方法を実施する、１つ又は複数のコンピューター読み取り可能記憶媒体。
請求項9
請求項８記載の１つ又は複数のコンピューター読み取り可能媒体において、１つのタイプがＵＲＬタイプを含む、１つ又は複数のコンピューター読み取り可能媒体。
請求項10
請求項８記載の１つ又は複数のコンピューター読み取り可能媒体において、１つのタイプが履歴タイプを含む、１つ又は複数のコンピューター読み取り可能媒体。
請求項11
請求項８記載の１つ又は複数のコンピューター読み取り可能媒体において、１つのタイプがお気に入りタイプを含む、１つ又は複数のコンピューター読み取り可能媒体。
請求項12
請求項８記載の１つ又は複数のコンピューター読み取り可能媒体において、前記１つのタイプがＲＳＳタイプを含む、１つ又は複数のコンピューター読み取り可能媒体。
請求項13
請求項８記載の１つ又は複数のコンピューター読み取り可能媒体において、タイプが、ＵＲＬタイプ、履歴タイプ、お気に入りタイプ、およびＲＳＳタイプを含む、１つ又は複数のコンピューター読み取り可能媒体。
請求項14
コンピューター実装方法であって、ユーザーが入力したクエリーが１単語よりも多いか否か確認するステップと、前記ユーザーが入力したクエリーが１単語よりも多くない場合、前記ユーザーが入力したクエリーの前にプロトコル・ストリングおよび／またはＵＲＬが付いているか否か確認するステップと、前記ユーザーが入力したクエリーが１単語よりも多くなく、しかもプロトコル・ストリングおよび／またはＵＲＬが当該クエリーの前に付いている場合、第１方法を用いて結果を戻すステップと、前記ユーザーが入力したクエリーが１単語よりも多くなく、しかもプロトコル・ストリングおよび／またはＵＲＩが当該クエリーの前に付いていない場合、第２の異なる方法を用いて結果を戻すステップと、前記ユーザーが入力したクエリーが１単語よりも多い場合、前記第２の異なる方法を用いて、結果を戻すステップと、を備えている、コンピューター実装方法。
請求項15
請求項１４記載の方法において、前記結果は、異なるタイプ毎に分類されて戻される、方法。
請求項16
請求項１４記載の方法において、前記第１方法は、宛先の抜き取られたＵＲＬとプレフィックス・ストリングの照合を行うために、クエリー単語からプロトコル・プレフィックスを抜き取る、方法。
請求項17
請求項１６記載の方法において、前記第１方法は、履歴タイプ、お気に入りタイプ、ＲＳＳフィードおよびフィード項目タイプ、ならびにタイプ入力したＵＲＬタイプにしたがって分類された結果を戻す、方法。
請求項18
請求項１４記載の方法において、前記第２方法は、１つ又は複数のクエリー単語に対して変更を行わず、単語分解を利用する、方法。
請求項19
請求項１８記載の方法において、前記第２方法は、履歴タイプ、お気に入りタイプ、ＲＳＳフィードおよびフィード項目タイプ、ならびにタイプ入力したＵＲＬタイプにしたがって分類された結果を戻す、方法。
請求項20
請求項１４記載の方法において、前記第１方法は、宛先の抜き取られたＵＲＬとプレフィックス・ストリングの照合を行うために、クエリー単語からプロトコル・プレフィックスを抜き取り、前記第２方法は、１つ又は複数のクエリー単語に対して変更を行わず、単語分解を利用し、前記第１および第２方法は、履歴タイプ、お気に入りタイプ、ＲＳＳフィードおよびフィード項目タイプ、ならびにタイプ入力したＵＲＬタイプにしたがって分類された結果を戻す、方法。